SherbyNet - /page/wikibook/entry.mu

Micron Document

<!DOCTYPE html>

<title>Domain Name System</title>

</head>

<h1 id="firstHeading" class="firstHeading mw-first-heading">Domain Name System</h1>

</header>

</div>

/* start https://fr.wikipedia.org/ */

.mw-parser-output .entete.communication{background-image:url("./_mw_/Picto_infobox_antenna.png")}

/* end https://fr.wikipedia.org/ */

</style>

<div>Domain Name System</div>

</div>

<table><caption style="">Informations</caption>

<th scope="row"> Fonction

</th>

<td>

Résolution de <a href="Nom_de_domaine" title="Nom de domaine">nom de domaine</a> en <a href="Adresse_IP" title="Adresse IP">adresse IP</a></td>

</tr>

<tr>

<th scope="row"> <a href="Sigle" title="Sigle">Sigle</a>

</th>

<td>

DNS</td>

</tr>

<tr>

</th>

<td>

53</td>

</tr>

<tr>

</th>

<td>

</tr>

</tbody></table>

</div>

Le Domain Name System<a href="#cite_note-13">[13]</a> (Système de nom de domaine) ou DNS est un service <a href="Informatique_distribu%C3%A9e" class="mw-redirect" title="Informatique distribuée">informatique distribué</a> qui associe les <a href="Nom_de_domaine" title="Nom de domaine">noms de domaine</a> <a href="Internet" title="Internet">Internet</a> avec leurs <a href="Adresse_IP" title="Adresse IP">adresses IP</a> ou d'<a href="#Principaux_enregistrements_DNS">autres types d'enregistrements</a>. En fournissant dès les premières années d'Internet, autour de 1985, un service distribué de résolution de noms, le DNS est un composant essentiel du développement du <a href="R%C3%A9seau_informatique" title="Réseau informatique">réseau informatique</a>.

À la demande de l'<a href="Defense_Advanced_Research_Projects_Agency" title="Defense Advanced Research Projects Agency">agence américaine pour les projets de recherche avancée de défense</a> (DARPA), <a href="Jon_Postel" title="Jon Postel">Jon Postel</a> et <a href="Paul_Mockapetris" title="Paul Mockapetris">Paul Mockapetris</a> conçoivent le DNS et en rédigent la première implémentation en <a href="1983_en_informatique" title="1983 en informatique">1983</a>.

Les équipements (ou hôtes) connectés à un réseau IP, comme <a href="Internet" title="Internet">Internet</a>, possèdent une <a href="Adresse_IP" title="Adresse IP">adresse IP</a> qui les identifie sur le réseau. Ces adresses sont numériques afin de faciliter leur traitement par les machines. En <a href="IPv4" title="IPv4">IPv4</a>, elles sont représentées sous la forme « - - - . - - - . - - - . - - - », où chaque groupe de trois tirets est substituable par un nombre entre 0 et 255 (en représentation <a href="Syst%C3%A8me_d%C3%A9cimal" title="Système décimal">décimale</a>). En <a href="IPv6" title="IPv6">IPv6</a>, les adresses sont représentées sous la forme « .... : .... : .... : .... : .... : .... : .... : .... », où chaque groupe de quatre points est substituable par une valeur <a href="Hexad%C3%A9cimal" class="mw-redirect" title="Hexadécimal">hexadécimale</a> de 0000 à FFFF.

Pour faciliter l'accès aux hôtes sur un réseau IP, un mécanisme a été mis en place pour associer un nom à une adresse IP. Ce nom, plus simple à retenir qu'une suite de chiffres, est appelé « <a href="Nom_de_domaine" title="Nom de domaine">nom de domaine</a> ». Résoudre un nom de domaine consiste à trouver l'adresse IP qui lui est associée.

En plus des adresses IP, des informations complémentaires peuvent être associées aux noms de domaine comme des enregistrements dans le contexte de la lutte contre le <a href="Spam" title="Spam">spam</a> (<a href="Sender_Policy_Framework" title="Sender Policy Framework">SPF</a>), RRSIG pour la sécurité des informations du DNS (<a href="Domain_Name_System_Security_Extensions" title="Domain Name System Security Extensions">DNSSEC</a>) ou NAPTR pour associer des numéros de téléphone à des adresses e-mail (<a href="ENUM" title="ENUM">ENUM</a>).

<div class="mw-heading mw-heading2"><h2 id="Histoire">Histoire</h2></div>

Avant le DNS, la résolution d'un nom sur Internet devait se faire grâce à un fichier texte appelé HOSTS.TXT (<abbr class="abbr" title="Request for comments" lang="en">RFC</abbr> 608<a href="#cite_note-RFC-608-14">[14]</a>) maintenu par le <a href="Network_Information_Center" class="mw-redirect" title="Network Information Center">NIC</a> du <a href="SRI_International" title="SRI International">Stanford Research Institute</a> et copié sur chaque ordinateur du réseau par <a href="Transfert_de_fichier" title="Transfert de fichier">transfert de fichier</a>. En 1982, ce système centralisé montre ses limites et plusieurs propositions de remplacement voient le jour, parmi lesquelles le <a href="Calcul_distribu%C3%A9" title="Calcul distribué">système distribué</a> Grapevine de <a href="Xerox" title="Xerox">Xerox</a> et IEN 116<a href="#cite_note-15">[15]</a>. Le premier (Grapevine) est jugé trop compliqué tandis que le second (IEN 116) est insuffisant<a href="#cite_note-16">[16]</a>. C’est finalement l’équipe dirigée par <a href="Elizabeth_J._Feinler" title="Elizabeth J. Feinler">Elizabeth Feinler</a> au <a href="Network_information_center" title="Network information center">NIC</a> qui définira le Domain Name System afin de gérer la croissance de l'internet en déléguant la gestion des noms de domaine à des serveurs de noms distribués. <a href="Paul_Mockapetris" title="Paul Mockapetris">Paul Mockapetris</a> publie la conception du système dans les <abbr class="abbr" title="Request for comments" lang="en">RFC</abbr> 882<a href="#cite_note-RFC-882-1">[1]</a> et <abbr class="abbr" title="Request for comments" lang="en">RFC</abbr> 883<a href="#cite_note-RFC-883-2">[2]</a> en 1983. La <a href="Norme" title="Norme">norme</a> correspondante est publiée dans les <abbr class="abbr" title="Request for comments" lang="en">RFC</abbr> 1034<a href="#cite_note-RFC-1034-3">[3]</a> et <abbr class="abbr" title="Request for comments" lang="en">RFC</abbr> 1035<a href="#cite_note-RFC-1035-4">[4]</a> en 1987. En 1987, le fichier HOSTS.TXT contenait 5 500 entrées, tandis que 20 000 hôtes étaient définis dans le DNS.

<div class="mw-heading mw-heading2"><h2 id="Un_système_hiérarchique_et_distribué">Un système hiérarchique et distribué</h2></div>

<div class="mw-heading mw-heading3"><h3 id="Hiérarchie_du_DNS">Hiérarchie du DNS</h3></div>

Le système des noms de domaine consiste en une hiérarchie dont le sommet est appelé la racine. On représente cette dernière par un point.

Dans un domaine, on peut créer un ou plusieurs sous-domaines ainsi qu'une délégation pour ceux-ci, c'est-à-dire une indication que les informations relatives à ce sous-domaine sont enregistrées sur un autre serveur. Ces sous-domaines peuvent à leur tour déléguer des sous-domaines vers d'autres serveurs.

Tous les sous-domaines ne sont pas nécessairement délégués. Les délégations créent des zones, c'est-à-dire des ensembles de domaines et leurs sous-domaines non délégués qui sont configurés sur un serveur déterminé. Les zones sont souvent confondues avec les domaines.

Les domaines se trouvant immédiatement sous la racine sont appelés <a href="Domaine_de_premier_niveau" title="Domaine de premier niveau">domaine de premier niveau</a> (Top Level Domain, TLD). Les noms de domaines ne correspondant pas à une extension de pays sont appelés des domaines génériques (gTLD), par exemple .org ou .com. S'ils correspondent à des codes de pays (fr, be, ch, etc.), ce sont des <a href="Domaine_de_premier_niveau_national" title="Domaine de premier niveau national">domaines de premier niveau national</a>, aussi appelés ccTLD de l'anglais country code TLD.

On représente un nom de domaine en indiquant les domaines successifs séparés par un point, les noms de domaines supérieurs se trouvant à droite.

Par exemple, le domaine org. est un TLD, sous-domaine de la racine. Le domaine wikipedia.org. est un sous-domaine de .org. Cette délégation est accomplie en indiquant la liste des serveurs DNS associée au sous-domaine dans le domaine de niveau supérieur.

Les noms de domaines sont donc résolus en parcourant la hiérarchie depuis le sommet et en suivant les délégations successives, c'est-à-dire en parcourant le nom de domaine de droite à gauche.

Pour qu'il fonctionne normalement, un nom de domaine doit avoir fait l'objet d'une délégation correcte dans le domaine de niveau supérieur.

<div class="mw-heading mw-heading3"><h3 id="Résolution_du_nom_par_un_hôte">Résolution du nom par un hôte</h3></div>

Les hôtes (ordinateurs des utilisateurs finaux) n'ont qu'une connaissance limitée du système des noms de domaine. Quand ils doivent résoudre un nom, ils s'adressent à un ou plusieurs serveurs de noms dits récursifs (ou résolveur) ou bien ils recherchent l'information dans les caches, comme ceux des navigateurs ou bien ceux des résolveurs eux-mêmes.

Il y a deux types de serveurs DNS: les résolveurs (aussi appelés récursifs, bien qu'ils travaillent de manière itérative) et les serveurs faisant autorité<a href="#cite_note-17">[17]</a>. Les serveurs DNS récursifs ne font qu'interroger les serveurs faisant autorité. Les serveurs faisant autorité détiennent les informations DNS sur les domaines sur lesquels ils ont autorité.

Les serveurs récursifs vont parcourir la hiérarchie DNS et faire suivre la requête à un ou plusieurs autres serveurs de noms ayant autorité pour fournir une réponse. Les adresses IP de ces serveurs récursifs sont souvent obtenues par l'utilisateur final via <a href="Dynamic_host_configuration_protocol" class="mw-redirect" title="Dynamic host configuration protocol">DHCP</a> ou encore configurés en dur sur la machine hôte de l'utilisateur. Les <a href="Fournisseur_d'acc%C3%A8s_%C3%A0_Internet" title="Fournisseur d'accès à Internet">fournisseurs d'accès à Internet</a> mettent à disposition de leurs clients ces serveurs récursifs. Il existe également des serveurs récursifs publics comme ceux de <a href="Cloudflare" title="Cloudflare">Cloudflare</a>, Yandex.DNS, <a href="Google_Public_DNS" title="Google Public DNS">Google Public DNS</a>, <a href="OpenNIC" title="OpenNIC">OpenNIC</a> ou <a href="FDN" class="mw-redirect" title="FDN">FDN</a>.

Quand l'ordinateur d'un utilisateur a besoin de charger une page internet de fr.wikipedia.org, il s'adresse d'abord à un serveur récursif pour trouver l'adresse IP (ie l'adresse numérique) de fr.wikipedia.org. Pour trouver l'adresse IP de fr.wikipedia.org, le serveur DNS récursif démarre un processus itératif pour consulter la hiérarchie DNS: Ce serveur demande à des serveurs DNS ayant autorité appelés <a href="Serveurs_DNS_Racine" class="mw-redirect" title="Serveurs DNS Racine">serveurs racine</a> quels serveurs ont autorité pour la zone org. Parmi ceux fournis dans la réponse, le serveur récursif va en choisir un pour lui demander quels serveurs ont autorité pour la zone wikipedia.org. C'est un de ces derniers qui pourra lui donner l'adresse IP de fr.wikipedia.org. S'il se trouve qu'un serveur ne répond pas, un autre serveur de la liste sera consulté.

Pour optimiser les requêtes ultérieures, les serveurs DNS récursifs font aussi office de DNS cache : ils gardent en mémoire (cache) la réponse d'une résolution de nom afin de ne pas effectuer ce processus à nouveau ultérieurement. Cette information est conservée pendant une période nommée Time to live et associée à chaque nom de domaine. Il existe aussi un cache au niveau du navigateur de l'utilisateur et eventuellement de son système d'exploitation.

Un nom de domaine peut être défini, à l'identique, dans plusieurs serveurs DNS ayant autorité. Généralement, les noms de domaines en utilisent au moins deux : un primaire et un secondaire. Il peut y avoir plusieurs serveurs secondaires.

L'ensemble des serveurs primaires et secondaires font autorité pour un domaine, c'est-à-dire que la réponse ne fait pas appel à un autre serveur ou à un cache. Les serveurs récursifs fournissent des réponses qui ne sont pas nécessairement à jour, à cause du cache mis en place. On parle alors de réponse ne faisant pas autorité (non-authoritative answer).

Cette architecture garantit au réseau Internet une certaine continuité dans la résolution des noms. Quand un serveur DNS tombe en panne, le bon fonctionnement de la résolution de nom n'est pas remis en cause dans la mesure où des serveurs secondaires sont disponibles.

<div class="mw-heading mw-heading3"><h3 id="Résolution_inverse">Résolution inverse</h3></div>

Pour trouver le nom de domaine associé à une adresse IP, on utilise un principe semblable. Dans un nom de domaine, la partie la plus générale est à droite : org dans fr.wikipedia.org, le mécanisme de résolution parcourt donc le nom de domaine de droite à gauche. Dans une adresse IP V4, c'est le contraire : 213 est la partie la plus générale de 213.228.0.42. Pour conserver une logique cohérente, on inverse l'ordre des quatre termes de l'adresse et on la concatène au pseudo domaine in-addr.arpa. Ainsi, pour trouver le nom de domaine de l'adresse IP 91.198.174.2, on résout 2.174.198.91.in-addr.arpa.

La déclaration inverse est importante sur les adresses IP publiques Internet puisque l'absence d'une résolution inverse est considérée comme une erreur opérationnelle (<abbr class="abbr" title="Request for comments" lang="en">RFC</abbr> 1912<a href="#cite_note-RFC-1912-18">[18]</a>) qui peut entraîner le refus d'accès à un service. Par exemple, un <a href="Serveur_de_messagerie_%C3%A9lectronique" title="Serveur de messagerie électronique">serveur de messagerie électronique</a> se présentant en envoi avec une adresse IP n'ayant pas de résolution inverse (PTR) a de grandes chances de se voir refuser, par l'hôte distant, la transmission du courrier (message de refus de type : IP lookup failed).

De plus, cette résolution inverse est importante dans le cadre de la réalisation de diagnostics réseaux car c'est elle qui permet de rendre les résultats de la commande <a href="Traceroute" title="Traceroute">traceroute</a> humainement exploitables. Les dénominations des noms d'hôtes inverses sont souvent des composites de sous-domaines de localisation (ville, région, pays) et de domaines explicites indiquant le fournisseur d'accès Internet traversé comme francetelecom.net (- - - -.nctou202.Toulouse.francetelecom.net) et opentransit.net (- - - -.Aubervilliers.opentransit.net) pour <a href="France_T%C3%A9l%C3%A9com" title="France Télécom">France Télécom</a>, ou encore proxad.net (- - - -.intf.routers.proxad.net) pour <a href="Free_(soci%C3%A9t%C3%A9)" class="mw-redirect" title="Free (société)">Free</a>.

Une adresse IP peut être associée à différents noms de domaine via l'enregistrement de plusieurs entrées PTR dans le sous-domaine <a href=".arpa" title=".arpa">.arpa</a> consacré à cette adresse (in-addr.arpa. pour <a href="IPv4" title="IPv4">IPv4</a> et ip6.arpa. pour <a href="IPv6" title="IPv6">IPv6</a>). L'utilisation d'enregistrements PTR multiples pour une même adresse IP est éventuellement présente dans le cadre de l'hébergement virtuel de multiples domaines <a href="World_Wide_Web" title="World Wide Web">web</a> derrière la même adresse IP mais n'est pas recommandée dans la mesure où le nombre des champs PTR à renvoyer peut faire dépasser à la réponse la taille des paquets <a href="User_Datagram_Protocol" title="User Datagram Protocol">UDP</a> de réponse et entraîner l'utilisation du protocole <a href="Transmission_Control_Protocol" title="Transmission Control Protocol">TCP</a> (plus coûteux en ressources) pour envoyer la réponse à la requête DNS<a href="#cite_note-19">[19]</a>.

<div class="mw-heading mw-heading4"><h4 id="Résolution_inverse_CIDR">Résolution inverse CIDR</h4></div>

Les délégations des zones inverses se font sur une frontière d'octet, ce qui fonctionne quand les blocs d'adresses sont distribués de façon <a href="Classe_d'adresse_IP" title="Classe d'adresse IP">classful</a> mais pose des problèmes quand les blocs assignés sont de taille quelconque.

Par exemple, si deux clients A et B disposent chacun des blocs 192.168.0.0/25 et 192.168.0.128/25, il n'est pas possible de déléguer 0.168.192.in-addr.arpa. au premier pour qu'il puisse définir les PTR correspondant à ses hôtes, car cela empêcherait le second de faire de même.

La <abbr class="abbr" title="Request for comments" lang="en">RFC</abbr> 2317<a href="#cite_note-RFC-2317-20">[20]</a> a défini une approche pour traiter ce problème, elle consiste à faire usage de domaines intermédiaires et de CNAME.

<div class="mw-highlight mw-highlight-lang-text mw-content-ltr" dir="ltr"><pre>$ORIGIN 0.168.192.in-addr.arpa.

0/25 NS ns.clientA.fr.

128/25 NS ns.clientB.fr.

0 CNAME 0.0/25.0.168.192.in-addr.arpa.

1 CNAME 1.0/25.0.168.192.in-addr.arpa.

...

127 CNAME 127.0/25.0.168.192.in-addr.arpa.

128 CNAME 128.128/25.0.168.192.in-addr.arpa.

...

255 CNAME 255.128/25.0.168.192.in-addr.arpa.

</pre></div>

Le client A définit la zone 0/25.0.168.192.in-addr.arpa. :

<div class="mw-highlight mw-highlight-lang-text mw-content-ltr" dir="ltr"><pre>$ORIGIN 0/25.0.168.192.in-addr.arpa.

1 PTR hote1.clientA.fr.

...

127 PTR hote127.clientA.fr.

</pre></div>

Le client B fait de même pour 128/25.0.168.192.in-addr.arpa. et les adresses 128 à 255.

La résolution inverse de 192.168.0.1 aboutira aux requêtes suivantes :

<div class="mw-highlight mw-highlight-lang-text mw-content-ltr" dir="ltr"><pre>1.0.168.192.in-addr.arpa. CNAME 1.0/25.0.168.192.in-addr.arpa.

1.0/25.0.168.192.in-addr.arpa. PTR hote1.clientA.fr.

</pre></div>

Ce qui assure le fonctionnement de la résolution inverse, moyennant un niveau d'indirection supplémentaire.

<div class="mw-heading mw-heading2"><h2 id="Serveurs_DNS_racine">Serveurs DNS racine</h2></div>

Les serveurs racine sont gérés par douze organisations différentes : deux sont européennes, une japonaise et les neuf autres sont américaines. Sept de ces serveurs sont en réalité distribués dans le monde grâce à la technique <a href="Anycast" title="Anycast">anycast</a> et, en 2025, ils disposent tous d'une adresse <a href="IPv6" title="IPv6">IPv6</a><a href="#cite_note-21">[21]</a>. Grâce à anycast, plus de 200 serveurs répartis dans 50 pays du monde assurent ce service<a href="#cite_note-22">[22]</a>. Il existe 13 autorités de nom appelées de a à m.root-servers.net. Le serveur k reçoit par exemple de l'ordre de 70 000 à 100 000 requêtes par seconde en <time class="nowrap" datetime="2019-04" data-sort-value="2019-04">avril 2019</time><a href="#cite_note-23">[23]</a>.

Le DNS ne fournit pas de mécanisme pour découvrir la liste des <a href="Serveurs_DNS_Racine" class="mw-redirect" title="Serveurs DNS Racine">serveurs racine</a>, chacun des serveurs doit donc connaître cette liste au démarrage grâce à un codage explicite. Cette liste est ensuite mise à jour en consultant l'un des serveurs indiqués. La mise à jour de cette liste est peu fréquente de façon que les serveurs anciens continuent à fonctionner.

<div class="mw-heading mw-heading2"><h2 id="Fully_Qualified_Domain_Name">Fully Qualified Domain Name</h2></div>

On entend par Fully Qualified Domain Name (FQDN, Nom de domaine pleinement qualifié) un nom de domaine écrit de façon absolue, y compris tous les domaines jusqu'au <a href="Domaine_de_premier_niveau" title="Domaine de premier niveau">domaine de premier niveau</a> (TLD), il est ponctué par un point final, par exemple fr.wikipedia.org.

La norme prévoit qu'un élément d'un nom de domaine (appelé label) ne peut dépasser 63 caractères, un FQDN ne pouvant dépasser 253 caractères.

<div class="mw-heading mw-heading2"><h2 id="Nom_de_domaine_internationalisé">Nom de domaine internationalisé</h2></div>

Dans leur définition initiale, les noms de domaines sont constitués des caractères de A à Z (sans différence de <a href="Casse_(typographie)" title="Casse (typographie)">casse</a> : les lettres capitales ne sont pas différenciées), de chiffres et du trait d'union.

La <abbr class="abbr" title="Request for comments" lang="en">RFC</abbr> 3490<a href="#cite_note-RFC-3490-24">[24]</a> définit un format appelé <a href="Punycode" title="Punycode">Punycode</a> qui permet l'encodage d'un jeu de caractère plus étendu.

<div class="mw-heading mw-heading2"><h2 id="Les_techniques_du_DNS_Round-Robin_pour_la_distribution_de_la_charge">Les techniques du DNS Round-Robin pour la distribution de la charge</h2></div>

Lorsqu'un service génère un trafic important, celui-ci peut faire appel à la technique du DNS <a href="Round-robin_(informatique)" title="Round-robin (informatique)">Round-Robin</a> (tourniquet DNS), une des techniques de <a href="R%C3%A9partition_de_charge" title="Répartition de charge">répartition de charge</a> qui consiste à associer plusieurs adresses IP à un <a href="Fully_qualified_domain_name" title="Fully qualified domain name">FQDN</a>. Les différentes versions de Wikipedia, comme fr.wikipedia.org par exemple, sont associées à plusieurs adresses IP : 207.142.131.235, 207.142.131.236, 207.142.131.245, 207.142.131.246, 207.142.131.247 et 207.142.131.248. L'ordre dans lequel ces adresses sont renvoyées sera modifié d'une requête à la suivante. Une rotation circulaire entre ces différentes adresses permet ainsi de répartir la charge générée par ce trafic important entre les différentes machines ayant ces adresses IP. Il faut cependant nuancer cette répartition car elle n'a lieu qu'à la résolution du nom d'hôte et reste par la suite en cache sur les différents resolvers (client DNS).

<div class="mw-heading mw-heading2"><h2 id="Principaux_types_d'enregistrements_DNS">Principaux types d'enregistrements DNS</h2></div>

Le type d'enregistrement de ressource (RR, Resource Record) est codé sur 16 bits<a href="#cite_note-25">[25]</a>, l'<a href="IANA" class="mw-redirect" title="IANA">IANA</a> conserve le registre des codes assignés<a href="#cite_note-26">[26]</a>. Les principaux types d'enregistrements définis sont les suivants :

<ul><li>A record ou address record (également appelé enregistrement d’hôte) qui fait correspondre un nom d'hôte ou un nom de domaine ou un sous-domaine à une adresse IPv4 de 32 bits distribués sur quatre octets ex: 123.234.1.2 ;</li>

<li>AAAA record ou IPv6 address record qui fait correspondre un nom d'hôte à une adresse IPv6 de 128 bits distribués sur seize octets ;</li>

<li>CNAME record ou canonical name record qui permet de faire un alias d'un domaine vers un autre.</li>

<li><a href="Enregistrement_Mail_eXchanger" title="Enregistrement Mail eXchanger">MX record</a> ou mail exchange record qui définit les serveurs de courriel pour ce domaine ;</li>

<li>PTR record ou pointer record qui associe une adresse IP à un enregistrement de nom de domaine, aussi dit « reverse » puisqu'il fait exactement le contraire du A record ;</li>

<li>NS record ou name server record qui définit les serveurs DNS de ce domaine ;</li>

<li>SOA record ou Start Of Authority record qui donne les informations générales de la zone : serveur principal, courriel de contact, différentes durées dont celle d'expiration, numéro de série de la zone ;</li>

<li><a href="Enregistrement_SRV" class="mw-redirect" title="Enregistrement SRV">SRV record</a> qui généralise la notion de MX record, mais qui propose aussi des fonctionnalités avancées comme le taux de répartition de charge pour un service donné, standardisé dans la <abbr class="abbr" title="Request for comments" lang="en">RFC</abbr> 2782<a href="#cite_note-RFC-2782-27">[27]</a> ;</li>

<li>NAPTR record ou Name Authority Pointer record qui donne accès à des règles de <a href="R%C3%A9%C3%A9criture_(informatique)" title="Réécriture (informatique)">réécriture</a> de l'information, permettant des correspondances assez lâches entre un nom de domaine et une ressource. Il est spécifié dans la <abbr class="abbr" title="Request for comments" lang="en">RFC</abbr> 3403<a href="#cite_note-RFC-3403-28">[28]</a> ;</li>

<li>TXT record permet à un administrateur d'insérer un texte quelconque dans un enregistrement DNS (par exemple, cet enregistrement est utilisé pour implémenter la spécification <a href="Sender_Policy_Framework" title="Sender Policy Framework">Sender Policy Framework</a>) ;</li>

<li>d'autres types d'enregistrements sont utilisés occasionnellement, ils servent simplement à donner des informations (par exemple, un enregistrement de type LOC indique l'emplacement physique d'un hôte, c'est-à-dire sa latitude et sa longitude). Certaines personnes[Qui ?] disent que cela aurait un intérêt majeur mais n'est que très rarement utilisé sur le monde Internet.</li></ul>

<div class="mw-heading mw-heading3"><h3 id="NS_record">NS record</h3></div>

L'enregistrement NS crée une délégation d'un sous-domaine vers une liste de serveurs.

Dans la zone org, les enregistrements NS suivants créent le sous-domaine wikipedia et délèguent celui-ci vers les serveurs indiqués.

L'ordre des serveurs est quelconque. Tous les serveurs indiqués doivent faire autorité pour le domaine.

<div class="mw-highlight mw-highlight-lang-text mw-content-ltr" dir="ltr"><pre>wikipedia NS ns1.wikimedia.org.

wikipedia NS ns2.wikimedia.org.

wikipedia NS ns0.wikimedia.org.

</pre></div>

<div class="mw-heading mw-heading3"><h3 id="PTR_record">PTR record</h3></div>

À l'inverse d'une entrée de type A ou AAAA, une entrée PTR indique à quel nom d'hôte correspond une adresse <a href="IPv4" title="IPv4">IPv4</a> ou <a href="IPv6" title="IPv6">IPv6</a>. Si elle est spécifiée, elle doit contenir l'enregistrement inverse d'une entrée DNS A ou AAAA.

Par exemple (pour une adresse <a href="IPv4" title="IPv4">IPv4</a>) cet enregistrement PTR :

<div class="mw-highlight mw-highlight-lang-text mw-content-ltr" dir="ltr"><pre>232.174.198.91.in-addr.arpa. IN PTR text.esams.wikimedia.org.

</pre></div>

correspond à cette entrée A :

<div class="mw-highlight mw-highlight-lang-text mw-content-ltr" dir="ltr"><pre>text.esams.wikimedia.org. IN A 91.198.174.232

</pre></div>

Dans le cas d'une adresse <a href="IPv6" title="IPv6">IPv6</a>, les entrées de type PTR sont enregistrées dans la zone ip6.arpa. (pendant de la zone in-addr.arpa. des adresses <a href="IPv4" title="IPv4">IPv4</a>).

La règle permettant de retrouver l'entrée correspondant à une adresse <a href="IPv6" title="IPv6">IPv6</a> est similaire à celle pour les adresses <a href="IPv4" title="IPv4">IPv4</a> (renversement de l'adresse et recherche dans un sous-domaine dédié de la zone arpa.), mais diffère au niveau du nombre de bits de l'adresse utilisés pour rédiger le nom du domaine où rechercher le champ PTR : là où pour <a href="IPv4" title="IPv4">IPv4</a> le découpage de l'adresse se fait par octet, pour <a href="IPv6" title="IPv6">IPv6</a> c'est un découpage par <a href="Quartet_(informatique)" class="mw-redirect" title="Quartet (informatique)">quartet</a> qui est utilisé.

Par exemple à l'adresse IPv6 :

<div class="mw-highlight mw-highlight-lang-text mw-content-ltr" dir="ltr"><pre>2001:610:240:22::c100:68b

</pre></div>

correspond le nom de domaine :

<div class="mw-highlight mw-highlight-lang-text mw-content-ltr" dir="ltr"><pre>b.8.6.0.0.0.1.c.0.0.0.0.0.0.0.0.2.2.0.0.0.4.2.0.0.1.6.0.1.0.0.2.ip6.arpa. PTR www.ipv6.ripe.net.

</pre></div>

<div class="mw-heading mw-heading3"><h3 id="MX_record">MX record</h3></div>

Une entrée DNS MX indique les serveurs <a href="Simple_Mail_Transfer_Protocol" title="Simple Mail Transfer Protocol">SMTP</a> à contacter pour envoyer un courriel à un utilisateur d'un domaine donné. Par exemple :

<div class="mw-highlight mw-highlight-lang-text mw-content-ltr" dir="ltr"><pre>wikimedia.org. IN MX 10 mchenry.wikimedia.org.

wikimedia.org. IN MX 50 lists.wikimedia.org.

</pre></div>

On voit que les courriels envoyés à une adresse en @wikimedia.org sont envoyés au serveur mchenry.wikimedia.org. ou lists.wikimedia.org. Le nombre précédant le serveur représente la priorité. Le serveur avec la priorité numérique la plus petite est employé en priorité. Ici, c'est donc mchenry.wikimedia.org. qui doit être utilisé en premier, avec une valeur de 10.

Les serveurs indiqués doivent avoir été configurés pour accepter de relayer les courriers pour le nom de domaine indiqué. Une erreur courante consiste à indiquer des serveurs quelconques comme serveurs secondaires, ce qui aboutit au rejet des courriers quand le serveur primaire devient inaccessible. Il n'est pas indispensable de disposer de serveurs secondaires, les serveurs émetteurs conservant les messages pendant un temps déterminé (typiquement, plusieurs jours) jusqu'à ce que le serveur primaire soit à nouveau disponible.

Les entrées MX sont généralisées par les entrées SRV qui permettent de faire la même chose mais pour tous les services, pas seulement <a href="Simple_Mail_Transfer_Protocol" title="Simple Mail Transfer Protocol">SMTP</a> (le courriel). L'avantage des entrées SRV par rapport aux entrées MX est aussi qu'elles permettent de choisir un port arbitraire pour chaque service ainsi que de faire de la <a href="R%C3%A9partition_de_charge" title="Répartition de charge">répartition de charge</a> plus efficacement. L'inconvénient c'est qu'il existe encore peu de programmes clients qui gèrent les entrées SRV. Cependant, depuis 2009, avec l'augmentation de l'utilisation du protocole <a href="Session_Initiation_Protocol" title="Session Initiation Protocol">SIP</a> sur les services de <a href="Voix_sur_IP" title="Voix sur IP">VoIP</a>, les enregistrements SRV deviennent plus fréquents dans les zones DNS.

<div class="mw-heading mw-heading3"><h3 id="CNAME_record">CNAME record</h3></div>

L'enregistrement CNAME permet de créer un alias.

Par exemple :

<div class="mw-highlight mw-highlight-lang-text mw-content-ltr" dir="ltr"><pre>fr.wikipedia.org. IN CNAME text.wikimedia.org.

text.wikimedia.org. IN CNAME text.esams.wikimedia.org.

text.esams.wikimedia.org. IN A 91.198.174.232

</pre></div>

Celui-ci exclut tout autre enregistrement (<abbr class="abbr" title="Request for comments" lang="en">RFC</abbr> 1034<a href="#cite_note-RFC-1034-3">[3]</a> section 3.6.2, <abbr class="abbr" title="Request for comments" lang="en">RFC</abbr> 1912<a href="#cite_note-RFC-1912-18">[18]</a> section 2.4), c'est-à-dire qu'on ne peut avoir à la fois un CNAME et un A record pour le même nom de domaine.

Par exemple, ceci est interdit :

<div class="mw-highlight mw-highlight-lang-text mw-content-ltr" dir="ltr"><pre>fr.wikipedia.org. IN CNAME text.wikimedia.org.

fr.wikipedia.org. IN A 91.198.174.232

</pre></div>

Par ailleurs, pour des raisons de performance, et pour éviter les boucles infinies du type

<div class="mw-highlight mw-highlight-lang-text mw-content-ltr" dir="ltr"><pre>fr.wikipedia.org. IN CNAME text.wikimedia.org.

text.wikipedia.org. IN CNAME fr.wikimedia.org.

</pre></div>

les spécifications (<abbr class="abbr" title="Request for comments" lang="en">RFC</abbr> 1034<a href="#cite_note-RFC-1034-3">[3]</a> section 3.6.2, <abbr class="abbr" title="Request for comments" lang="en">RFC</abbr> 1912<a href="#cite_note-RFC-1912-18">[18]</a> section 2.4) recommandent de ne pas faire pointer un CNAME sur un autre CNAME ni sur un DNAME (alias pour un nom et tous ses sous-noms).

Ainsi, le premier exemple serait préférablement enregistré de la façon suivante :

<div class="mw-highlight mw-highlight-lang-text mw-content-ltr" dir="ltr"><pre>fr.wikipedia.org. IN CNAME text.esams.wikimedia.org.

text.wikimedia.org. IN CNAME text.esams.wikimedia.org.

text.esams.wikimedia.org. IN A 91.198.174.232

</pre></div>

<div class="mw-heading mw-heading3"><h3 id="NAPTR_record">NAPTR record</h3></div>

Peu répandus à l'heure actuelle (ils sont surtout utilisés par <a href="ENUM" title="ENUM">ENUM</a>), ils décrivent une réécriture d'une clé (un nom de domaine) en <a href="Uniform_Resource_Identifier" title="Uniform Resource Identifier">URI</a>. Par exemple, dans ENUM, des enregistrements NAPTR peuvent être utilisés pour trouver l'adresse de courrier électronique d'une personne, connaissant son numéro de téléphone (qui sert de clé à ENUM).

Ses paramètres sont dans l'ordre :

<ol><li>Order : indique dans quel ordre évaluer les enregistrements NAPTR ; tant qu'il reste des enregistrements d'une certaine valeur de order à examiner, les enregistrements des valeurs suivantes de order n'entrent pas en considération ;</li>

<li>Preference : donne une indication de priorité relative entre plusieurs enregistrements NAPTR qui ont la même valeur de order ;</li>

<li>Flags : indique par exemple si l'enregistrement décrit une réécriture transitoire (dont le résultat est un nom de domaine pointant sur un autre enregistrement NAPTR) ou une réécriture finale ; la sémantique précise du paramètre flags dépend de l'application DDDS ('Dynamic Delegation Discovery System', <abbr class="abbr" title="Request for comments" lang="en">RFC</abbr> 3401<a href="#cite_note-RFC-3401-29">[29]</a>) employée (<a href="ENUM" title="ENUM">ENUM</a> en est une parmi d'autres) ;</li>

<li>Services : décrit le service de réécriture ; par exemple dans <a href="ENUM" title="ENUM">ENUM</a>, la valeur de services spécifie le type de l'<a href="Uniform_Resource_Identifier" title="Uniform Resource Identifier">URI</a> résultante ; la sémantique précise de ce paramètre dépend également de l'application DDDS employée ;</li>

<li>Regexp : l'opération de réécriture elle-même, formalisée en une <a href="Expression_rationnelle" class="mw-redirect" title="Expression rationnelle">expression rationnelle</a> ; cette expression rationnelle est à appliquer à la clé ; ne peut être fourni en même temps que replacement ;</li>

<li>Replacement : nom de domaine pointant sur un autre enregistrement NAPTR, permettant par exemple une réécriture transitoire par délégation ; ne peut être fourni en même temps que regexp.</li></ol>

L'enregistrement NAPTR est défini par la <abbr class="abbr" title="Request for comments" lang="en">RFC</abbr> 3403<a href="#cite_note-RFC-3403-28">[28]</a>.

<div class="mw-heading mw-heading3"><h3 id="SOA_record">SOA record</h3></div>

Cet enregistrement permet d'indiquer le serveur de nom maître (primaire), l'adresse e-mail d'un contact technique (avec @ remplacé par un point) et des paramètres d'expiration.

Il désigne l'autorité (start of authority) ou le responsable de la zone dans la hiérarchie DNS. C'est l'acte de naissance de la zone DNS.

Ces paramètres sont dans l'ordre :

<div class="mw-highlight mw-highlight-lang-text mw-content-ltr" dir="ltr"><pre>wikipedia.org. IN SOA ns0.wikimedia.org. hostmaster.wikimedia.org. 2010060311 43200 7200 1209600 3600

</pre></div>

<ol><li>Serial : indique un numéro de version pour la zone (32 bits non signé). Ce nombre doit être incrémenté à chaque modification du fichier zone ; on utilise par convention une date au format « yyyymmddnn » (« yyyy » pour l'année sur 4 chiffres, « mm » pour le mois sur 2 chiffres, « dd » pour le jour sur 2 chiffres, « nn » pour un compteur de révision si le numéro de série est modifié plusieurs fois dans un même jour. Cette convention évite tout débordement du 32 bits non signé jusqu'en l'an 4294) ;</li>

<li>Refresh : l'écart en secondes entre les demandes successives de mise à jour réalisées depuis le serveur secondaire ou les serveurs esclaves ;</li>

<li>Retry : le délai en secondes que doivent attendre le serveur secondaire ou les serveurs esclaves lorsque leur précédente requête a échoué ;</li>

<li>Expire : le délai en secondes au terme duquel la zone est considérée comme invalide si le secondaire ou les esclaves ne peuvent joindre le serveur primaire ;</li>

<li>Minimum ou negative TTL : utilisé pour spécifier, en secondes, la durée de vie pendant laquelle sont conservées en cache les réponses qui correspondent à des demandes d'enregistrements inexistants.</li></ol>

Les versions récentes de BIND (named) acceptent les suffixes M, H, D ou W pour indiquer un intervalle de temps en minutes, heures, jours ou semaines respectivement.

Chaque enregistrement est associé à un Time To Live (TTL) qui détermine combien de temps il peut être conservé dans un serveur cache. Ce temps est typiquement d'un jour (86400 s) mais peut être plus élevé pour des informations qui changent rarement, comme des records NS. Il est également possible d'indiquer que des informations ne doivent pas être mises en cache en spécifiant un TTL de zéro.

Certaines applications, comme des <a href="Navigateur_web" title="Navigateur web">navigateurs web</a> disposent également d'un cache DNS, mais qui ne respecte pas nécessairement le TTL du DNS. Ce cache applicatif est généralement de l'ordre de la minute, mais <a href="Internet_Explorer" title="Internet Explorer">Internet Explorer</a> par exemple conserve les informations jusqu'à 30 minutes<a href="#cite_note-30">[30]</a>, indépendamment du TTL configuré.

<div class="mw-heading mw-heading2"><h2 id="Glue_records">Glue records</h2></div>

Quand un domaine est délégué à un serveur de noms qui appartient à ce sous-domaine, il est nécessaire de fournir également l'adresse IP de ce serveur pour éviter les références circulaires. Ceci déroge au principe général selon lequel l'information d'un domaine n'est pas dupliquée ailleurs dans le DNS.

Par exemple, dans la réponse suivante au sujet des NS pour le domaine wikimedia.org :

<div class="mw-highlight mw-highlight-lang-text mw-content-ltr" dir="ltr"><pre>wikimedia.org. IN NS ns2.wikimedia.org.

wikimedia.org. IN NS ns1.wikimedia.org.

wikimedia.org. IN NS ns0.wikimedia.org.

</pre></div>

Il est nécessaire de fournir également les adresses IP des serveurs indiqués dans la réponse (glue records<a href="#cite_note-31">[31]</a>), car ils font partie du domaine en question :

<div class="mw-highlight mw-highlight-lang-text mw-content-ltr" dir="ltr"><pre>ns0.wikimedia.org. IN A 208.80.152.130

ns1.wikimedia.org. IN A 208.80.152.142

ns2.wikimedia.org. IN A 91.198.174.4

</pre></div>

<div class="mw-heading mw-heading2"><h2 id="Mise_à_jour_dynamique">Mise à jour dynamique</h2></div>

Une extension du DNS nommée <a href="DNS_dynamique" title="DNS dynamique">DNS dynamique</a> (DDNS) permet à un client de mettre à jour une zone avec des informations qui le concernent (<abbr class="abbr" title="Request for comments" lang="en">RFC</abbr> 2136<a href="#cite_note-RFC-2136-32">[32]</a>). Ceci est utile quand des clients obtiennent une adresse IP par <a href="DHCP" class="mw-redirect" title="DHCP">DHCP</a> et qu'ils souhaitent que le DNS reflète le nom réel de la machine.

<div class="mw-heading mw-heading2"><h2 id="Considérations_opérationnelles">Considérations opérationnelles</h2></div>

Les mises à jour se font sur le serveur primaire du domaine, les serveurs secondaires recopiant les informations du serveur primaire dans un mécanisme appelé <a href="Transfert_de_zone_DNS" title="Transfert de zone DNS">transfert de zone</a>. Pour déterminer si un transfert de zone doit avoir lieu, le serveur secondaire consulte le numéro de version de la zone et le compare à la version qu'il possède. Le serveur primaire détermine à quelle fréquence le numéro de version est consulté. Quand un changement est effectué, les serveurs envoient des messages de notification aux serveurs secondaires pour accélérer le processus.

Il se peut que des informations qui ne sont plus à jour soient cependant conservées dans des serveurs cache. Il faut alors attendre l'expiration de leur TTL pour que ces informations cachées disparaissent et donc que la mise à jour soit pleinement effective. On peut minimiser le temps nécessaire en diminuant le TTL associé aux noms de domaines qui vont être modifiées préalablement à une opération de changement.

<div class="mw-heading mw-heading3"><h3 id="Cohérence_du_DNS">Cohérence du DNS</h3></div>

Quand la liste des serveurs de noms change, ou quand une adresse IP qui fait l'objet d'un Glue Record est modifiée, le gestionnaire du domaine de niveau supérieur doit effectuer la mise à jour correspondante.

<div class="mw-heading mw-heading3"><h3 id="Robustesse_du_DNS">Robustesse du DNS</h3></div>

Pour éviter les <a href="Point_individuel_de_d%C3%A9faillance" class="mw-redirect" title="Point individuel de défaillance">points individuels de défaillance</a>, on évite de partager l'infrastructure entre les serveurs qui font autorité. Un serveur secondaire sera de préférence délocalisé et routé différemment du serveur primaire.

Bien que cela soit techniquement possible, on évite de mêler sur un même serveur le rôle de DNS récursif et celui de serveur qui fait autorité.

De même, un hôte sera configuré avec plusieurs serveurs récursifs, de sorte que si le premier ne répond pas à la requête, le suivant sera employé.

En général, les serveurs récursifs fournis par les FAI refusent les requêtes émanant d'adresses IP appartenant à d'autres FAI.

Il existe des services de DNS récursifs ouverts, c'est-à-dire qu'ils acceptent les requêtes de tous les clients. Il est donc possible à un utilisateur de configurer ceux-ci en lieu et place de ceux fournis par le FAI. Ceci pose cependant les problèmes suivants :

<ul><li>il n'y a pas de garantie que les réponses fournies seront les mêmes qu'avec des serveurs récursifs habituels. Un tel service pourrait en effet faire référence à une autre hiérarchie depuis la racine, disposer de TLD additionnels non standard, restreindre l'accès à certains domaines, voire <a href="Manipulation_de_l'espace_des_noms_de_domaine" title="Manipulation de l'espace des noms de domaine">altérer certains records avant leur transmission</a> au client ;</li>

<li>il n'y a pas de garantie de confidentialité, c'est-à-dire que ce service pourrait déterminer à quels domaines un utilisateur a accès en conservant des traces des requêtes DNS.</li></ul>

<div class="mw-heading mw-heading2"><h2 id="Sécurité_du_DNS">Sécurité du DNS</h2></div>

Le protocole DNS a été conçu avec un souci minimum de la sécurité. Plusieurs failles de sécurité du protocole DNS ont été identifiées depuis. Les principales failles du DNS ont été décrites dans le <abbr class="abbr" title="Request for comments" lang="en">RFC</abbr> 3833<a href="#cite_note-RFC-3833-33">[33]</a> publié en <time class="nowrap" datetime="2004-08" data-sort-value="2004-08">août 2004</time>.

<div class="mw-heading mw-heading3"><h3 id="Interception_des_paquets">Interception des paquets</h3></div>

Une des failles mises en avant est la possibilité d'intercepter les paquets transmis. Les serveurs DNS communiquent au moyen de paquets uniques et non signés. Ces deux spécificités rendent l'interception très aisée. L'interception peut se concrétiser de différentes manières, notamment via une attaque de type « man in the middle », de l'écoute des données transférées et de l'envoi de réponse falsifiée (voir paragraphe ci-dessous).

<div class="mw-heading mw-heading3"><h3 id="Fabrication_d'une_réponse">Fabrication d'une réponse</h3></div>

Les paquets des serveurs DNS étant faiblement sécurisés, authentifiés par un numéro de requête, il est possible de fabriquer de faux paquets. Par exemple, un utilisateur qui souhaite accéder au site <a rel="nofollow" class="external free" href="http://mabanque.example.com">http://mabanque.example.com</a> fait une demande au site DNS. Il suffit, à ce moment, qu'un pirate informatique réponde à la requête de l'utilisateur avant le serveur DNS pour que l'utilisateur se retrouve sur un site d'<a href="Phishing" class="mw-redirect" title="Phishing">hameçonnage</a>.

<div class="mw-heading mw-heading3"><h3 id="Corruption_des_données">Corruption des données</h3></div>

La trahison par un serveur, ou corruption de données, est, techniquement, identique à une interception des paquets. La seule différence venant du fait que l'utilisateur envoie volontairement sa requête au serveur. Cette situation peut arriver lorsque, par exemple, l'opérateur du serveur DNS souhaite mettre en avant un partenaire commercial.

<div class="mw-heading mw-heading3"><h3 id="Empoisonnement_du_cache_DNS">Empoisonnement du cache DNS</h3></div>

L'empoisonnement du cache DNS ou pollution de cache DNS (en anglais, DNS Cache Poisoning) est une technique permettant de leurrer les serveurs DNS afin de leur faire croire qu'ils reçoivent une requête valide tandis qu'elle est frauduleuse<a href="#cite_note-34">[34]</a>.

<div class="mw-heading mw-heading3"><h3 id="Déni_de_service">Déni de service</h3></div>

Une attaque par déni de service, ou attaque par saturation, (en anglais, Denial of Service attack ou DoS attack) est une attaque sur un serveur informatique qui résulte en l'incapacité pour le serveur de répondre aux requêtes de ses clients.

<div class="mw-heading mw-heading3"><h3 id="DNSSEC">DNSSEC</h3></div>

Pour contrer les vulnérabilités dues à la corruption des données, l'empoisonnement de cache DNS, etc., le protocole <a href="DNSSEC" class="mw-redirect" title="DNSSEC">DNSSEC</a> (<abbr class="abbr" title="Request for comments" lang="en">RFC</abbr> 4033<a href="#cite_note-RFC-4033-35">[35]</a>, <abbr class="abbr" title="Request for comments" lang="en">RFC</abbr> 4034<a href="#cite_note-RFC-4034-36">[36]</a>, <abbr class="abbr" title="Request for comments" lang="en">RFC</abbr> 4035<a href="#cite_note-RFC-4035-37">[37]</a>) a été développé. Il utilise les principes de <a href="Cryptographie_asym%C3%A9trique" title="Cryptographie asymétrique">cryptographie asymétrique</a> et de <a href="Signature_num%C3%A9rique" title="Signature numérique">signature numérique</a> pour garantir l'intégrité des données, ainsi qu'une preuve de non-existence si l'enregistrement demandé n'existe pas. La <a href="Zone_racine_du_DNS" title="Zone racine du DNS">zone racine du DNS</a> a été signée le <time class="nowrap" datetime="2010-07-15" data-sort-value="2010-07-15">15 juillet 2010</time><a href="#cite_note-38">[38]</a>, et le déploiement de DNSSEC sur les TLD continue, une <a href="Liste_des_domaines_Internet_de_premier_niveau" title="Liste des domaines Internet de premier niveau">liste des domaines couverts</a> étant disponible.

<div class="mw-heading mw-heading3"><h3 id="Chiffrement">Chiffrement</h3></div>

Depuis 2015<a href="#cite_note-39">[39]</a>, l'<a href="Internet_Engineering_Task_Force" title="Internet Engineering Task Force">Internet Engineering Task Force</a> (IETF) travaille à la sécurité du canal de communication du DNS (là où DNSSEC protège les données). Cela a débouché sur la publication de plusieurs RFC permettant l'utilisation de <a href="Transport_Layer_Security" title="Transport Layer Security">TLS</a> afin de chiffrer la communication entre les clients DNS et les résolveurs. Il s'agit principalement de : <a href="DNS_over_TLS" title="DNS over TLS">DNS sur TLS</a> (<abbr class="abbr" title="Request for comments" lang="en">RFC</abbr> 7858<a href="#cite_note-RFC-7858-40">[40]</a>, utilisant le port 853) et <a href="DNS_over_HTTPS" title="DNS over HTTPS">DNS sur HTTPS</a> (<abbr class="abbr" title="Request for comments" lang="en">RFC</abbr> 8484<a href="#cite_note-RFC-8484-11">[11]</a>, requête DNS encapsulée dans une requête <a href="HTTP" class="mw-redirect" title="HTTP">HTTP</a>, et traitée par un <a href="Serveur_web" title="Serveur web">serveur web</a>).

Il n'y a pas, en 2018, de possibilités de chiffrer – via TLS – les communications entre un résolveur et un serveur faisant autorité.

<div class="mw-heading mw-heading3"><h3 id="Exemple_d'attaques_majeures_contre_des_serveurs_DNS">Exemple d'attaques majeures contre des serveurs DNS</h3></div>

En <time class="nowrap" datetime="2008-07" data-sort-value="2008-07">juillet 2008</time>, quelques jours après la publication du rapport de la <a href="United_States_Computer_Emergency_Readiness_Team" title="United States Computer Emergency Readiness Team">United States Computer Emergency Readiness Team</a> concernant la faille de sécurité des serveurs DNS permettant d'empoisonner leur cache, plusieurs serveurs DNS majeurs ont subi des attaques. Une des plus importantes fut celle menée contre les serveurs de <a href="AT%26T" title="AT&T">AT&T</a>. L'attaque empoisonnant le cache des serveurs DNS de AT&T a permis au pirate informatique de rediriger toutes les requêtes de Google vers un site d'<a href="Phishing" class="mw-redirect" title="Phishing">hameçonnage</a><a href="#cite_note-41">[41]</a>.

<div class="mw-heading mw-heading2"><h2 id="Détails_du_protocole">Détails du protocole</h2></div>

DNS utilise en général <a href="User_Datagram_Protocol" title="User Datagram Protocol">UDP</a> et le <a href="Port_(logiciel)" title="Port (logiciel)">port</a> 53. La taille maximale des paquets utilisée est de 512 octets. Si une réponse dépasse cette taille, la norme prévoit que la requête doit être renvoyée sur le port TCP 53. Ce cas est cependant rare et évité, et les firewalls bloquent souvent le port TCP 53.

L'extension <a href="EDNS" title="EDNS">EDNS</a>0 (<abbr class="abbr" title="Request for comments" lang="en">RFC</abbr> 2671<a href="#cite_note-RFC-2671-42">[42]</a>) permet d'utiliser une taille de paquets plus élevée, sa prise en charge est recommandée pour IPv6 comme pour DNSSEC.

La norme prévoit qu'il existe une classe associée aux requêtes. Les classes IN (Internet), CH (Chaos) et HS (Hesiod <a href="https://en.wikipedia.org/wiki/Hesiod_(name_service)" class="extiw external" title="en:Hesiod (name service)">(en)</a>) sont définies, seule la classe IN étant réellement utilisée en pratique. La classe chaos est utilisée par <a href="BIND" title="BIND">BIND</a> pour révéler le numéro de version<a href="#cite_note-43">[43]</a>.

<div class="mw-heading mw-heading2"><h2 id="Exemples_de_consultation_DNS">Exemples de consultation DNS</h2></div>

Pour vérifier l'association entre un nom et une adresse IP, plusieurs commandes sont disponibles suivant les systèmes d'exploitation utilisés.

Par exemple sur Windows la commande <a href="Nslookup" title="Nslookup">nslookup</a> est disponible via l'invite de commande :

<div class="mw-highlight mw-highlight-lang-text mw-content-ltr" dir="ltr"><pre>> nslookup www.google.fr

Serveur : Livebox-6370

Address: 192.168.1.1

Réponse ne faisant pas autorité :

Nom : www.l.google.com

Addresses:

209.85.229.104

209.85.229.106

209.85.229.103

209.85.229.147

209.85.229.105

209.85.229.99

Aliases: www.google.fr

www.google.com

</pre></div>

ou encore <a href="Dig_(programme_informatique)" title="Dig (programme informatique)">dig</a> sur les systèmes compatibles avec <a href="UNIX" class="mw-redirect" title="UNIX">UNIX</a> :

<div class="mw-highlight mw-highlight-lang-text mw-content-ltr" dir="ltr"><pre>> dig www.google.com aaaa

; <<>> DiG 9.7.0-P1 <<>> www.google.com aaaa

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47055

;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 4, ADDITIONAL: 0

;; QUESTION SECTION:

;www.google.com. IN AAAA

;; ANSWER SECTION:

www.google.com. 422901 IN CNAME www.l.google.com.

www.l.google.com. 77 IN AAAA 2a00:1450:8004::67

www.l.google.com. 77 IN AAAA 2a00:1450:8004::68

www.l.google.com. 77 IN AAAA 2a00:1450:8004::69

www.l.google.com. 77 IN AAAA 2a00:1450:8004::6a

www.l.google.com. 77 IN AAAA 2a00:1450:8004::93

www.l.google.com. 77 IN AAAA 2a00:1450:8004::63

;; AUTHORITY SECTION:

google.com. 155633 IN NS ns2.google.com.

google.com. 155633 IN NS ns1.google.com.

google.com. 155633 IN NS ns3.google.com.

google.com. 155633 IN NS ns4.google.com.

;; Query time: 0 msec

;; SERVER: ::1#53(::1)

;; WHEN: Sun May 23 16:23:49 2010

;; MSG SIZE rcvd: 292

</pre></div>

<div class="mw-heading mw-heading2"><h2 id="Exemples_d'adresses_de_serveurs_DNS">Exemples d'adresses de serveurs DNS</h2></div>

<a href="Cloudflare" title="Cloudflare">Cloudflare</a> : 1.1.1.1

<a href="Google_Public_DNS" title="Google Public DNS">Google Public DNS</a> : 8.8.8.8

<a href="OpenDNS" title="OpenDNS">OpenDNS</a> : 208.67.222.222

<a href="Quad9" title="Quad9">Quad9</a> : 9.9.9.9

<div class="mw-heading mw-heading2"><h2 id="Notes_et_références">Notes et références</h2></div>

<li id="cite_note-RFC-882-1"><abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> <a rel="nofollow" class="external text" href="https://tools.ietf.org/html/rfc882">Request for comments <abbr class="abbr" title="numéro">no</abbr> 882</a>

</li>

<li id="cite_note-RFC-883-2"><abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> <a rel="nofollow" class="external text" href="https://tools.ietf.org/html/rfc883">Request for comments <abbr class="abbr" title="numéro">no</abbr> 883</a>

</li>

<li id="cite_note-RFC-1034-3"><abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> <a rel="nofollow" class="external text" href="https://tools.ietf.org/html/rfc1034">Request for comments <abbr class="abbr" title="numéro">no</abbr> 1034</a>

</li>

<li id="cite_note-RFC-1035-4"><abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> <a rel="nofollow" class="external text" href="https://tools.ietf.org/html/rfc1035">Request for comments <abbr class="abbr" title="numéro">no</abbr> 1035</a>

</li>

<li id="cite_note-RFC-1591-5"><a href="#cite_ref-RFC-1591_5-0">↑</a> <abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> <a rel="nofollow" class="external text" href="https://tools.ietf.org/html/rfc1591">Request for comments <abbr class="abbr" title="numéro">no</abbr> 1591</a>

</li>

<li id="cite_note-RFC-6195-6"><a href="#cite_ref-RFC-6195_6-0">↑</a> <abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> <a rel="nofollow" class="external text" href="https://tools.ietf.org/html/rfc6195">Request for comments <abbr class="abbr" title="numéro">no</abbr> 6195</a>

</li>

<li id="cite_note-RFC-6895-7"><a href="#cite_ref-RFC-6895_7-0">↑</a> <abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> <a rel="nofollow" class="external text" href="https://tools.ietf.org/html/rfc6895">Request for comments <abbr class="abbr" title="numéro">no</abbr> 6895</a>

</li>

<li id="cite_note-RFC-8375-8"><a href="#cite_ref-RFC-8375_8-0">↑</a> <abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> <a rel="nofollow" class="external text" href="https://tools.ietf.org/html/rfc8375">Request for comments <abbr class="abbr" title="numéro">no</abbr> 8375</a>

</li>

<li id="cite_note-RFC-8467-9"><a href="#cite_ref-RFC-8467_9-0">↑</a> <abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> <a rel="nofollow" class="external text" href="https://tools.ietf.org/html/rfc8467">Request for comments <abbr class="abbr" title="numéro">no</abbr> 8467</a>

</li>

<li id="cite_note-RFC-8483-10"><a href="#cite_ref-RFC-8483_10-0">↑</a> <abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> <a rel="nofollow" class="external text" href="https://tools.ietf.org/html/rfc8483">Request for comments <abbr class="abbr" title="numéro">no</abbr> 8483</a>

</li>

<li id="cite_note-RFC-8484-11"><abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> <a rel="nofollow" class="external text" href="https://tools.ietf.org/html/rfc8484">Request for comments <abbr class="abbr" title="numéro">no</abbr> 8484</a>

</li>

<li id="cite_note-RFC-8499-12"><a href="#cite_ref-RFC-8499_12-0">↑</a> <abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> <a rel="nofollow" class="external text" href="https://tools.ietf.org/html/rfc8499">Request for comments <abbr class="abbr" title="numéro">no</abbr> 8499</a>

</li>

<li id="cite_note-13"><a href="#cite_ref-13">↑</a> <a rel="nofollow" class="external text" href="https://www.cloudflare.com/learning/dns/what-is-dns/">What is DNS? | How DNS works | Cloudflare</a>

</li>

<li id="cite_note-RFC-608-14"><a href="#cite_ref-RFC-608_14-0">↑</a> <abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> <a rel="nofollow" class="external text" href="https://tools.ietf.org/html/rfc608">Request for comments <abbr class="abbr" title="numéro">no</abbr> 608</a>

</li>

<li id="cite_note-15"><a href="#cite_ref-15">↑</a> <a rel="nofollow" class="external text" href="http://www.postel.org/ien/pdf/ien116.pdf">IEN 116</a> Internet Name Server, <a href="Jon_Postel" title="Jon Postel">Jon Postel</a> 1979

</li>

<li id="cite_note-16"><a href="#cite_ref-16">↑</a> <a rel="nofollow" class="external text" href="http://cseweb.ucsd.edu/classes/wi01/cse222/papers/mockapetris-dns-sigcomm88.pdf">Development of the Domain Name System</a>, <a href="Paul_Mockapetris" title="Paul Mockapetris">Paul Mockapetris</a>, Kevin Dunlap, Sigcomm 1988

</li>

<li id="cite_note-17"><a href="#cite_ref-17">↑</a> « <a rel="nofollow" class="external text" href="https://www.bortzmeyer.org/serveur-dns-faisant-autorite.html"><cite style="font-style:normal;">serveur faisant autorité</cite></a> », sur bortzmeyer.org (consulté le <time class="nowrap" datetime="2022-09-27" data-sort-value="2022-09-27">27 septembre 2022</time>)

</li>

<li id="cite_note-RFC-1912-18"><abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> <a rel="nofollow" class="external text" href="https://tools.ietf.org/html/rfc1912">Request for comments <abbr class="abbr" title="numéro">no</abbr> 1912</a>

</li>

<li id="cite_note-19"><a href="#cite_ref-19">↑</a> Voir la section 4.4 Usage and deployment considerations du draft <a rel="nofollow" class="external text" href="http://tools.ietf.org/html/draft-ietf-dnsop-reverse-mapping-considerations-06">draft-ietf-dnsop-reverse-mapping-considerations</a>

</li>

<li id="cite_note-RFC-2317-20"><a href="#cite_ref-RFC-2317_20-0">↑</a> <abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> <a rel="nofollow" class="external text" href="https://tools.ietf.org/html/rfc2317">Request for comments <abbr class="abbr" title="numéro">no</abbr> 2317</a>

</li>

<li id="cite_note-21"><a href="#cite_ref-21">↑</a> <abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> « <a rel="nofollow" class="external text" href="https://www.internic.net/domain/named.root"><cite style="font-style:normal;" lang="en">named.root</cite></a> », sur www.internic.net

</li>

<li id="cite_note-22"><a href="#cite_ref-22">↑</a> « <a rel="nofollow" class="external text" href="https://root-servers.org/"><cite style="font-style:normal;">Root Server Technical Operations Assn</cite></a> », sur root-servers.org (consulté le <time class="nowrap" datetime="2019-04-28" data-sort-value="2019-04-28">28 avril 2019</time>)

</li>

<li id="cite_note-23"><a href="#cite_ref-23">↑</a> <a rel="nofollow" class="external text" href="http://k.root-servers.org/index.html#stats">k statistics</a>

</li>

<li id="cite_note-RFC-3490-24"><a href="#cite_ref-RFC-3490_24-0">↑</a> <abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> <a rel="nofollow" class="external text" href="https://tools.ietf.org/html/rfc3490">Request for comments <abbr class="abbr" title="numéro">no</abbr> 3490</a>

</li>

<li id="cite_note-25"><a href="#cite_ref-25">↑</a> <abbr class="abbr" title="Request for comments" lang="en">RFC</abbr> 1035, chapitre 3.2.1

</li>

<li id="cite_note-26"><a href="#cite_ref-26">↑</a> « <a rel="nofollow" class="external text" href="https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml"><cite style="font-style:normal;">Domain Name System (DNS) Parameters</cite></a> », sur www.iana.org (consulté le <time class="nowrap" datetime="2019-04-28" data-sort-value="2019-04-28">28 avril 2019</time>)

</li>

<li id="cite_note-RFC-2782-27"><a href="#cite_ref-RFC-2782_27-0">↑</a> <abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> <a rel="nofollow" class="external text" href="https://tools.ietf.org/html/rfc2782">Request for comments <abbr class="abbr" title="numéro">no</abbr> 2782</a>

</li>

<li id="cite_note-RFC-3403-28"><abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> <a rel="nofollow" class="external text" href="https://tools.ietf.org/html/rfc3403">Request for comments <abbr class="abbr" title="numéro">no</abbr> 3403</a>

</li>

<li id="cite_note-RFC-3401-29"><a href="#cite_ref-RFC-3401_29-0">↑</a> <abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> <a rel="nofollow" class="external text" href="https://tools.ietf.org/html/rfc3401">Request for comments <abbr class="abbr" title="numéro">no</abbr> 3401</a>

</li>

<li id="cite_note-30"><a href="#cite_ref-30">↑</a> « <a rel="nofollow" class="external text" href="https://support.microsoft.com/fr-fr/help/263558/how-internet-explorer-uses-the-cache-for-dns-host-entries"><cite style="font-style:normal;">Comment Internet Explorer utilise le cache pour les entrées d’hôte DNS</cite></a> », sur support.microsoft.com (consulté le <time class="nowrap" datetime="2019-04-28" data-sort-value="2019-04-28">28 avril 2019</time>)

</li>

<li id="cite_note-31"><a href="#cite_ref-31">↑</a> « <a rel="nofollow" class="external text" href="https://docs.gandi.net/fr/noms_domaine/utilisateurs_avances/glue_records.html"><cite style="font-style:normal;">Glue Records (enregistrements Glue) — Documentation Documentation Gandi</cite></a> », sur docs.gandi.net (consulté le <time class="nowrap" datetime="2019-04-28" data-sort-value="2019-04-28">28 avril 2019</time>)

</li>

<li id="cite_note-RFC-2136-32"><a href="#cite_ref-RFC-2136_32-0">↑</a> <abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> <a rel="nofollow" class="external text" href="https://tools.ietf.org/html/rfc2136">Request for comments <abbr class="abbr" title="numéro">no</abbr> 2136</a>

</li>

<li id="cite_note-RFC-3833-33"><a href="#cite_ref-RFC-3833_33-0">↑</a> <abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> <a rel="nofollow" class="external text" href="https://tools.ietf.org/html/rfc3833">Request for comments <abbr class="abbr" title="numéro">no</abbr> 3833</a>

</li>

<li id="cite_note-34"><a href="#cite_ref-34">↑</a> <abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> « <a rel="nofollow" class="external text" href="https://www.kb.cert.org/vuls/id/800113/"><cite style="font-style:normal;" lang="en">Multiple DNS implementations vulnerable to cache poisoning</cite></a> », sur www.kb.cert.org (consulté le <time class="nowrap" datetime="2019-04-28" data-sort-value="2019-04-28">28 avril 2019</time>)

</li>

<li id="cite_note-RFC-4033-35"><a href="#cite_ref-RFC-4033_35-0">↑</a> <abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> <a rel="nofollow" class="external text" href="https://tools.ietf.org/html/rfc4033">Request for comments <abbr class="abbr" title="numéro">no</abbr> 4033</a>

</li>

<li id="cite_note-RFC-4034-36"><a href="#cite_ref-RFC-4034_36-0">↑</a> <abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> <a rel="nofollow" class="external text" href="https://tools.ietf.org/html/rfc4034">Request for comments <abbr class="abbr" title="numéro">no</abbr> 4034</a>

</li>

<li id="cite_note-RFC-4035-37"><a href="#cite_ref-RFC-4035_37-0">↑</a> <abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> <a rel="nofollow" class="external text" href="https://tools.ietf.org/html/rfc4035">Request for comments <abbr class="abbr" title="numéro">no</abbr> 4035</a>

</li>

<li id="cite_note-38"><a href="#cite_ref-38">↑</a> <abbr class="abbr indicateur-langue" title="Langue : anglais américain">(en-US)</abbr> « <a rel="nofollow" class="external text" href="https://www.root-dnssec.org/"><cite style="font-style:normal;" lang="en-us">Root DNSSEC</cite></a> » (consulté le <time class="nowrap" datetime="2019-08-25" data-sort-value="2019-08-25">25 août 2019</time>)

</li>

<li id="cite_note-39"><a href="#cite_ref-39">↑</a> « <a rel="nofollow" class="external text" href="https://tools.ietf.org/wg/dprive/"><cite style="font-style:normal;">Dprive Status Pages</cite></a> », sur tools.ietf.org (consulté le <time class="nowrap" datetime="2019-04-28" data-sort-value="2019-04-28">28 avril 2019</time>)

</li>

<li id="cite_note-RFC-7858-40"><a href="#cite_ref-RFC-7858_40-0">↑</a> <abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> <a rel="nofollow" class="external text" href="https://tools.ietf.org/html/rfc7858">Request for comments <abbr class="abbr" title="numéro">no</abbr> 7858</a>

</li>

<li id="cite_note-41"><a href="#cite_ref-41">↑</a> <abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> « <a rel="nofollow" class="external text" href="https://www.pcworld.com/article/149126/dns_attack_writer.html"><cite style="font-style:normal;" lang="en">DNS Attack Writer a Victim of His Own Creation</cite></a> », sur PCWorld, <time class="nowrap" datetime="2008-07-29" data-sort-value="2008-07-29">29 juillet 2008</time> (consulté le <time class="nowrap" datetime="2019-04-28" data-sort-value="2019-04-28">28 avril 2019</time>)

</li>

<li id="cite_note-RFC-2671-42"><a href="#cite_ref-RFC-2671_42-0">↑</a> <abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> <a rel="nofollow" class="external text" href="https://tools.ietf.org/html/rfc2671">Request for comments <abbr class="abbr" title="numéro">no</abbr> 2671</a>

</li>

<li id="cite_note-43"><a href="#cite_ref-43">↑</a> dig CH @k.root-servers.net version.bind txt

</li>

</ol></div>

</div>

<div class="mw-heading mw-heading2"><h2 id="Voir_aussi">Voir aussi</h2></div>

/* start https://fr.wikipedia.org/ */

.mw-parser-output .autres-projets>.titre{text-align:center;margin:0.2em 0}.mw-parser-output .autres-projets>ul{margin:0;padding:0}.mw-parser-output .autres-projets>ul>li{list-style:none;margin:0.2em 0;text-indent:0;padding-left:24px;min-height:20px;text-align:left;display:block}.mw-parser-output .autres-projets>ul>li>a{font-style:italic}@media(max-width:720px){.mw-parser-output .autres-projets{float:none}}

/* end https://fr.wikipedia.org/ */

</style>

<div class="mw-heading mw-heading3"><h3 id="Articles_connexes">Articles connexes</h3></div>

<ul><li><a href="Black_hole_(informatique)#DNS_Black_holing" class="mw-redirect" title="Black hole (informatique)">DNS black holing</a></li>

<li><a href="DNS_Black_Listing" title="DNS Black Listing">DNS Black Listing</a></li>

<li><a href="Empoisonnement_du_cache_DNS" title="Empoisonnement du cache DNS">Empoisonnement du cache DNS</a></li>

<li><a href="H%C3%A9bergement_de_nom_de_domaine" title="Hébergement de nom de domaine">Hébergement de nom de domaine</a></li>

<li><a href="Hosts" title="Hosts">Hosts</a></li>

<li><a href="Internet_Corporation_for_Assigned_Names_and_Numbers" title="Internet Corporation for Assigned Names and Numbers">ICANN</a></li>

<li><a href="Manipulation_de_l'espace_des_noms_de_domaine" title="Manipulation de l'espace des noms de domaine">Manipulation de l'espace des noms de domaine</a> (DNS menteurs)</li>

<li><a href="Nslookup" title="Nslookup">nslookup</a></li>

<li><a href="Serveur_racine_du_DNS" title="Serveur racine du DNS">Serveur racine du DNS</a></li>

<li><a href="RadioDNS" title="RadioDNS">RadioDNS</a></li></ul>

</div>

<div class="mw-heading mw-heading3"><h3 id="Liens_externes">Liens externes</h3></div>

<ul><li><a rel="nofollow" class="external text" href="https://web.archive.org/web/20081128073423/https://www.afnic.fr/ext/dns/">Auto-formation au DNS par l'Afnic</a></li>

<li><a rel="nofollow" class="external text" href="http://www.frameip.com/dns/">DNS dans tous ses détails</a></li>

<li><a rel="nofollow" class="external text" href="https://web.archive.org/web/20131230013120/http://www.commentcamarche.net/contents/518-dns-systeme-de-noms-de-domaine">DNS sur le site commentcamarche.net</a></li>

<li><a rel="nofollow" class="external text" href="http://www.urec.cnrs.fr/IMG/pdf/cours.dns.pdf">Support Cours de l'UREC/CNRS sur le DNS</a><abbr class="abbr indicateur-format format-pdf" title="Document au format Portable Document Format (PDF)">[PDF]</abbr></li>

<li><a rel="nofollow" class="external text" href="http://www.firasofting.com/blog/2011/tester-les-serveurs-dns/">Tester la mise à jour des DNS</a></li>

<li><abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> <a rel="nofollow" class="external text" href="http://tools.ietf.org/html/rfc6195">RFC6195 relatives au DNS</a></li>

<li><abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> <a rel="nofollow" class="external text" href="http://tools.ietf.org/html/rfc1035">RFC1035 relatives au DNS</a></li>

<li><abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> <a rel="nofollow" class="external text" href="http://www.iana.org/protocols/">Information sur le DNS</a></li>

<li><abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> <a rel="nofollow" class="external text" href="http://blog.nominet.org.uk/tech/2006/07/14/naptr-records/">Bonne explication des NAPTR par Nominet</a></li></ul>

<div class="mw-heading mw-heading4"><h4 id="Bases_de_données_et_dictionnaires">Bases de données et dictionnaires</h4></div>

<li><div class="liste-horizontale">Notices dans des dictionnaires ou encyclopédies généralistes : <ul><li><a rel="nofollow" class="external text" href="https://www.britannica.com/topic/DNS">Britannica</a></li> <li><a rel="nofollow" class="external text" href="http://www.sapere.it/enciclopedia/DNS.html">Enciclopedia De Agostini</a></li> <li><a rel="nofollow" class="external text" href="https://www.enciclopedia.cat/EC-GEC-0522736.xml">Gran Enciclopèdia Catalana</a></li> <li><a rel="nofollow" class="external text" href="https://encyklopedia.pwn.pl/haslo/;3982215">Internetowa encyklopedia PWN</a></li> </ul></div></li>

<li><div class="liste-horizontale"><a href="Autorit%C3%A9_(sciences_de_l'information)" title="Autorité (sciences de l'information)">Notices d'autorité</a> : <ul><li><a rel="nofollow" class="external text" href="http://d-nb.info/gnd/4348318-5">GND</a></li> <li><a rel="nofollow" class="external text" href="https://id.ndl.go.jp/auth/ndlna/001311891">Japon</a></li> <li><a rel="nofollow" class="external text" href="https://dbn.bn.org.pl/descriptor-details/9810532434805606">Pologne</a></li> </ul></div></li></ul>

</div>

<ul id="bandeau-portail" class="bandeau-portail"><li> Portail des réseaux informatiques </li> <li> Portail des télécommunications </li> <li> Portail de l’informatique </li> <li> Portail d’Internet </li> </ul></div><div><div class="zim-footer">

Cet article est issu de <a class="external text" title="Dernière modification le 2025-10-20" href="https://fr.wikipedia.org/wiki/?title=Domain_Name_System&oldid=229904627">Wikipédia</a>. Sauf mention contraire, le texte est disponible sous <a class="external text" href="https://creativecommons.org/licenses/by-sa/4.0/deed.fr">Creative Commons Attribution-Share Alike 4.0</a>. Des conditions supplémentaires peuvent s’appliquer aux fichiers multimédias.

</div>

</div></div>

</div>

</main>

</div>

</body></html>